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GAME CONTROL DEVICE HAVING GENRE DATA 

RFT ATED APPLICATIONS 
5 This is a continuation-in-part application of a prior US Patent Application 

filed January 10, 2000, titled "Mapping Input-Device Functions to Software 
Application Input Commands," serial number 09/483,113. Priority is hereby 
claimed to this earlier application. 

10 TECHNICAL FIELD 

This invention relates generally to the use of peripheral input devices with 
sofbvare applications and more specifically to the use of genres in conjunction with 
such mput devices and software applications. 

15 BACKGROUND OF THE INVENTION 

Various input devices are available that permit a computer user to 
commimicate with a computer. A typical persoriai computer offers input devices 
such as a keyboard and a mouse. Numerous other devices are available, such as 
drawing pads, joysticks, and steering wheels (for use with driving games). These 
20 d^icK can be connected to a cornputer, and they permit the user to communicate 
tafdrmation to the compu^ the information cbmmiinicated instructs software 
applications running on the coihputer to perform specified actions. 

ideally, a computer usef loads a software application, connects an 
appropriate desvice to the computer, and the device and software work together 
25 without further configuratioii by the user. This ideal, however, has not been 
realized in prior systems. 
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applications on the system and configures the device to work better with those 
applications. However, these ad hoc approaches are error prone, may result in a 
relationship between device controls and software actions that feels unnatural to the 
user, and can only provide support for applications the device manufacturer knows 
5 about and chooses to support. 

The Human Interface Device (HID) standard, defined in conjunction with 
the Universal Serial Bus (USB) standard, addresses problems such as these. Using 
HID, an input device can store information about its controls. This information can 
be obtained by a requesting application program. 
10 HID data generally describes the characteristics of device controls and the 

format of data generated by the controls; In addition, HID allows different labels or 
"usages" to be assigned to the controls of an input device. For example, a button 
might be designated as a "fire" button, as "buttonl", "button!," etc. In addition, 
HID can include "aliases" for a control. A given control might have a plurality of 
15 aliases such as '^uttonl," "fire," "torpedo," etc. 

Usages and aliases, if used in a uniform and agreed upon way, provide useful 
hints about how to use a certain control on an input device. In some cases, for 
instance, the "fire" button will have an obviously corresponding action in an 
application program. In other cases, however, the usages and aliases might not 
20 correspond directly to any terminology known by the application program. 

A further complicating factor is that there is no agreed upon standard for 
naming HH) controls. Even if there were such a standard, it would remain — ^in may 
cases — a very difficult task for an application program to determine an optimum set 
of mappings between numerous input device controls and the actions available in 
25 the application program. A determination such as this would require a complex 
algorithm, tailored specifically for the application program. 
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the HID data. The actions specified in the non-HlD data use these same string 
indexes to specify controls. 

BPTFF DESCRIPTION OF THE DRAWINGS 
5 Fig. 1 is a block diagram representing a computer system in which aspects of 

the invention may be incorporated; 

Fig. 2 is a block diagram showing the use of an input device mapper with 
input devices and software applications; 

Fig. 3 is a block diagram showing a sample control-semantic correlation and 

10 its structure; * 

Fig. 4 is a block diagram showing a sample action-semantic correlation, and 

its structure; 

' Fig. 5 is a block diagram showing a sample mapping created by an input 
device mapper; 

15 ' Fig! 6' is an image of ah input device with action labels; 

Fig. 7 is a flowchart illustrating a process by which an input device mapper 
is used; 

Fig. 8 is a block diagram showing the use of a mapping created by an input 

' "■■'device mapping; ■ ■ ■ 

20 ' Fig. 9 is a block diagram of an 'exemplary computer and game control 

- 'device;: ^ / .-^ ^" ^^i'r: : -^^-^ -^^--^ ■ - 

Fig. 1 0 is a block diagram of a rion-HID data descriptor; ^ 
- Fig. 11 is a flowchart showing methodological aspects of the described 
embodimerit. 

25 Figs. 12 and 13 are flowcharts showing methodological aspects of a USB 

implementation. 
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basic input/output system 26 (BIOS), containing the basic routines that help to 
transfer information between elements within the personal computer 20, such as 
during start-up, is stored in ROM 24. The personal computer 20 may further 
include a hard disk drive 27 for reading from and writing to a hard disk, not shown, 
5 a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 
29, and an optical disk drive 30 for reading from or writing to a removable optical 
disk 31 such as a CD-ROM or other optical media. The hard disk drive 27, 
magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 
by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical 
10 drive interface 34, respectively. The drives and their associated computer-readable 
media provide non-volatile storage of computer readable instructions, data 
structures, program modules and other data for the personal computer 20. AltKdugh 
the exempl^y environment described herein employs a hard disk, a removable 
magnetic disk 29 and a removable optical disk 31, it should be appreciated by those 
15 skilled in the art that other types of computer readable media which can store data 
that is accessible by a computer, such as magnetic cassettes, flash memory cards, 
digital video disks, Bernoulli cartridges, random access memories (RAMs), 
read-only memories (ROMs) and the like may also be used in the exemplary 
operating environment. ^ 
20 A number of program modules may be stored on the hard disk, magnetic disk 

29, optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or 
more application programs 36, other program modules 37, program data 38, and an 
input device mapper 39. A user may enter commands and information into the 
personal computer 20 through input devices such as a keyboard 40, a pointing 
25 device 42, a drawing pad 65, or a game controller such as driving game controller 
66. Other input devices (not shown) may include a microphone, joystick, game pad, 
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and other means of establishing a communications Unlc between the computers may 
be used. 

Input Device Mapper 

5 Figure 2 depicts the use of an input device manager. Input device mapper 39 

is a software module that provides an interface between application programs 36 
and input devices, such as devices 42, 65. 66, and 67. Input device mapper 39 
could be a system services component of an operating system running on computer 
20, such as operating system 35, or a stand-alone software module, as shown in Fig. 

10 2. 

Input device mapper 39 is associated with one or more genre descriptions, 
such as genre descriptions 211-213. An application program genre is a collection 
of games having similarities in operation and input device usage. A genre 
description for a specific genre defines mappings between input device controls and 
15 actions to be pMormed'm These actions are defined in terms 

semantics or labels. 

^ In thd system' described below, agreed upon' genre semantics or labels are 
preferably publicized so that input device manufacturers and software developers 
can use input device mapper 39 in the manner described below to allow devices and 
20 software to work together. Specifically, a plurality of genres are defined and a set 
of possible actions is defined for each genre. This will be explained in more detail 
below. - ■ ' ■ - - '■■ ■■■ ' 

In Fig. 2, genre description 211 corresponds to a "driving game" genre 
- (corresponding to example genre 1 in the Examples section below). Genre 
25 description 212 corresponds to a "role playing" genre (corresponding to example 
genre 3 in the Examples section below). Genre description 213 corresponds to a 
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semantics selected from the defined semantics of the driving simulation genre. 
Architectural design application 36b provides an A-S correlation between its 
actions and the defined semantics of the CAD genre. In addition to A-S correlation 
231, driving game application 36a also provides A-S correlation 232 between its 
5 actions and the defined semantics of the role-playing genre. Providing two 
different A-S correlations for a single application is appropriate when the 
application has two different phases that require different usage of the controls. For 
example, in driving game application 36a, the character begins by driving a car; this 
phase of the game is in driving simulation genre 211. Later, the character gets out 
10 of the car and explores on foot; this phase is in the role-playing genre 212. 

Input device mapper 39 receives C-S correlations 221-225 andfc,,A-S 
correlations 231-233. Input device mapper 39 creates a mapping for each 
application program 36a, 36b, on computer 20. For example, in order to create 
mapping 220 for driving game application 36a, input device mapper 39 first selects 
15 an appropriate device for the driving game genre, by determining which devices 
have a C-S correlation for the driving simulation genre. If there is more than one 
device having a C-S correlation for driving simulation genre 211, such as driving 
game controller 66 and joystick 67, then input device mapper 39 selects one of 
these devices. The selection may be made in various ways, for example by 
20 selecting the first appropriate connected device that input device mapper 39 locates, 
or by consulting a database of preferred devices for each genre. For example, input 
device mapper 39 selects game controller 66 because it is the first device that it 
locates which supports driving simulation genre 211. Once the device is selected, 
input device mapper 39 uses C-S correlation 221 and A-S correlation 231 to map 
25 controls on game controller 66 into actions that driving game application 36a 
performs. Input device mapper 39 may create the mapping by performing a simple 



wo 00/59594 PCT/USOO/08848 

.13 

described as "turn left or right" is associated with the semantic "STEER", "speed 
up" is associated with the semantic "ACCELERATE", etc. 

Figure 5 depicts a sample mapping 220 created by input device mapper 39, 
which links the controls on game controller 66 with actions performed by driving 
5 game application 36a. Controls 301 are correlated with semantics, as defined in C- 
S correlation 221. The semantics are correlated with software actions 401, as 
defined in A-S correlation 231. In the example, "trigger 1" 502 on game controller 
66 is correlated with the semantic "FIRE" 503, which, in turn, is correlated with the 
software action 'Tire machine guns" 504. 
1 0 The detail of an entry in the niapping is shown in items 511-513. Each; entry 

contains a controller code 511, an application code 512, and a label 513i«frThe 
controller code 511 is the data that an input device generates when a particular 
control has been operated. For example, the game controller could signify that 
trigger 1 has been pressed by generating the number "1002." The application code 
15 ■ 512 is the item of inptit that in application expects to receive as an instruction to 
perform a particular actioii. For exanple, the input "64379" could instruct driving 
game application 36a to fire machine guns. Label 513 is a text string provided by 
application program 36a, which is a plain language description of the action that 
application program 36a will perform upon receiving application code 512 as its 
20 input. For example, "fire machine guns" is a label describing the action that will be 
performed by driving game application 36a when trigger 1 is depressed. The labels 
are helpfiil for displaying a graphic representation of the mapping, as described 
below in the text accompanying Fig. 6. 

A mapping can be bi-directional. For example, it will be observed that 
25 mapping 220 shows a software action "feedback" 509 mapped into the "vibrate" 
control 511 on game controller 66 through the semantic "RUMBLE" 510. A genre, 
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with the "DASHBOARD" semantic, driving game 36a may still correlate its 
"change dash display" action with the semantic "DASHBOARD," and input device 
mapper 39 will locate an appropriate auxiliary input for that action. In mapping 
220, auxiliary input 501 is selected by input device mapper 39 to implement the 
5 "DASHBOARD" semantic. Auxiliary input 501 may be a key on keyboard 40, an 
unused control on game controller 66 such as control 505, a pop-up menu that the 
user can control with pointing device 42, or any other mechanism by which the user 
can communicate with computer 20. 

The genres may be defined such that some semantics must be mapped to the 
10 primary input device selected by input device mapper 39 and may not be mapped to 
an auxiliary input outside of that device. For example, in the genres provided 
below in the Examples section, coiltrols are divided into the categories "priority 1" 
and "priority 2." A priority 1 control is a control that must be implemented on the 
primary input device and may not be implemented by an auxiliary input. A priority 
15 2 control is a control that may be implemented on the primary input device, if a 
control is available. For example, in the genre "driving sim without weapons" 
shown in below in the Examples Section, steering is a priority 1 control, so the 
"steer" semantic must be implemented on the primary input device selected by input 
device mapper 39, such as game controller 66. However, "dashboard" is a priority 
20 2 control, so it may be implemented by any type of auxiliary input. Some other 
controls, which may be designated as "priority 3," are never implemented by the 
device used for the mapping, and therefore the genres do not define semantics to 
correlate with these controls. For example, a game application may provide a pop- 
up menu to change the resolution mode of the screen (640x480, 1024x768, etc), 
25 select the background music accompanying the game, select weapons to be carried. 
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the user's choice as a general preference that joystick 67 should work similarly with 
all games in first-person genres (i.e., that button 602 should enable a cloaking 
device in any first-person game that offers a cloaking device). The user's 
preferences may be stored in a file or database for future use by the user. 
5 Additionally, storing the preferences in a file or database permits the preferences to 
be easily ported from computer 20 to any other machine on which input device 
mapper 39 has been implemented, thus permitting consistent mappings across 
several machines. 

Figure 7 is a flowchart showing an example use of an input device mapper, 
10 and the steps to initiate its use. As shown in Fig. 6 and described in detail below, a 
device and an application both undergo a setup phase, in which they passr^^heir 
respective C-S and A-S correlations to an input device mapper; the application 
program then receives and processes input in accordance with the mapping. 

Steps 701 through 704 relate to the setup of an application program for use 
15 with input device mapper 39. An application program, such as driving game 
application 36a; begins execution at step 701. At step 702, the application creates 
an array correlating actions with semantics. For example; application 36a could 
create an array representing A-S correlation 231. The array created at step 702 is 
passed to input device mapper 39 at step 703. ■ 
20 One method of representing A-S correlation 23 1 in the array created as step 

702 is to assign a Unique value to each action and to each semantic. For example, 
the semantics in genre 211, which are used in A-S correlation 231 and C-S 
correlation 221, maybe assigned unique values as follows: 1 represents "STEER", 
2 represents "ACCELERATE", etc. In a programming environment that supports 
25 symbolic constants, such as C++, it is convenient to represent the values as 
symbols. Input device mapper 39 may defme the set of available genres and assign 
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along with game controiler 66 on a medium such as magnetic disk 29 or optical disk 
31; this array can then be passed to input device mapper 39 at step 706 by loading it 
into computer 20 through magnetic drive 28 or optical drive 30. Alternatively, game 
controller 66 may be known to the designer of input device mapper 39, in which 
5 case the array may be built into input device mapper 39. 

Step 704 takes place after steps 703 and 706 have been completed. After 
input device mapper 39 has received the arrays created at step 702 and the array 
created at step 705, it creates a mapping, such as mapping 220, by the process 
described above in the text accompanying Fig^ 5. After the mapping has been 
10 created, input device mapper 39 may provide mapping information to application 
program 36a at step 704. The mapping information provided may ^include 
mformation about which device control is correlated with each application-defined 
action. If the mapping is provided to application program 36a at step 704, then 
application program 36a can use the mapping to convert notifications of device 
15 events into actions that application program36a performs. Alternatively, instead of 
providing the mapping to application program 36a, the mapping may be provided to 
an input device manager, which is depicted in Fig. 8 and described below, which 
uses the mapping to translate device event notifications into input for application 
program 36a. In the case where an input device manager is used to translate device 
20 event notifications into application program input, it is not necessary to provide the 
mapping to application program 36a, in which case step 704 can be omitted. 

Following step 704, application program 36a begins its input loop 709, 
which comprises listening for input at step 707, processing the input at step 708, 
and returning to step 707 to listen for more input. When the mapping has been 
25 provided to application program 36a at step 704, application program 36a can use 
the mapping to process the input. In this case, application program would receive 
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position -32 at time = 12, etc.), or a parameter further describing the device event 
(e.g., in addition to data signifying that motion along the x-axis has occurred, input 
device manager 801 may also provide data indicating the magnitude and direction 
of the motion, or data indicating the resulting position of the control). An 
5 application, such as driving game application 36a, may be interested in this 
information. For example, the firing of a weapon may become more rapid after 
trigger 1 has been depressed for more than one second. A different game 
application might cause a pinball cue or a slingshot to be pulled back further the 
longer a button has been depressed. 
10 Input device manager 801 may receive event notifications from multiple 

devices, and use the data received from multiple devices to report, unified 
instructions to an application. By doing so, it allows an application to be controlled 
by various devices while allowing the application to view its input as if it came 
from a single "unified" device. For example, the auxiliary input used to implement 
15 the "change dash display" action correlated with the "DASHBOARD" semantic in 
driving game 36a could be tKe "D" key on keyboard 40 (not shown in Fig. 8). Input 
^device manager 801 will receive notification that the "DASHBOARD" semantic 
has been pressed, and will translate this notification into an instruction to driving 
game application 36a. the source- of the input is transparent to application 36a, 
20 which knows only that it has received the instruction to perform the action 
correlated with the semaitic "DASHBOARD." Another possible application of 
rq)orting unified instructions from multiple devices is aggregation of devices (e.g., 
using a joystick 67 with a set of pedals that are physically connected to driving 
game controller 66). Alternatively, in some circumstances it may be useful for input 
25 device manager 801 not to unify the input from multiple devices and to inform 
application 36a which input device a particular input originated firom, for example 
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EXAMPLES 

The following are examples of genres. The semantics in each genre are 
divided into "priority 1" semantics and "priority 2" semantics, which are described 
below: 

Genre 1; Combat Driving sim. with weapons 
Priority 1 Controls 

Description 
left / right 
faster / slower 
Brake 

select next weapon 
fires selected weapon 
selects next available target 
pause, show menu of priority 2 & 3 controls 



Semantic 
Steer 

Accelerate 
10 Brake 

Weapons 
- Fire 
Target 
Menu 

15 Prioritv 2 Controls 
Semantic 
Look 
View 
Device 

20 Dashboard 
Press to talk 
Up shift 
Down shift 



Description 

forward / right / backward / left 

cycle through view options 

show device and controls 

select next dashboard / heads-up display option 

for voice communication 

select next higher gear 

select next lower gear Reverse from neutral 



wo 00/59594 

Genre 3: Role Plaving 
Priority 1 Controls 



PCT/USOO/08848 



25 



10 



15 



20 



Semantic 


DescriDtion 


Move 


forward / back / left / right 


Get 


pick up and carry item 


Qf»lprt Tnventorv 


select next inventory item 


Annlv 


use selected inventory item 


Attack 




Cast 


cast spell 


Talk 


communicate 


Crouch 


crouch, climb down, swim down 


Jump 


jump, climb up, swim up 


Menu 


pause, show nienu of priority 2 & 3 controls 


Priority 2 Controls 





Semantic Description 

Look forward or up / back or down / left / right (usually maps 

to point of view ("POV") on devices that have one) 
Map cycle through map options 

Display shbws next ori-screen display options, niaps, etc. 

Press to talk ^ voice communication (multi-player) 
Rotate turn body left / right 

Device displays input device and controls 
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Genre 5: Real Time Strategy 
Priority 1 Controls 

Semantic 

Scroll 



5 Select 
. Instruct 
Apply 
Team 
Building 
10 Menu 

Priority 2 Controls 
Semantic 
Map 
Display 
15 Press to talk 

Device 



Description 
up / down / left / right 
Select unit / object / item 
cycle through instructions 
apply selected instruction 
select next team (cycle through all) 
select next building 

pause, show menu of priority 2 & 3 controls 



Description 

cycle through map options 
shows next on-screen display options, maps, etc. 
voice communication (multi-player) 
displays input device and controls 
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Priority 1 Controls - pitching 



Semantic 


Descriotion 


Aim 


aim where to pitch 


Select 


cycle through pitch selections 


Jritcn m 




Pitch Out 


throw pitch outside of strike zone 


Base 


select base to throw to 


Throw 


throw to base 


Catch 


catch hit ball 


Menu 


pause, show menu of priority 2 & 3 controls 



Priority 1 Controls ■ fielding 

Semantic Descrit^tion 
Aim aim where to run or throw 

Nearest switch to fielder nearest to the ball 

15 ConservativeThrowmake conservative throw 

Aggressive Throw make aggressive throw 
Burst invoke burst of speed 

Jump jump to catch ball 

Dive dive to catch ball 

20 Menu pause, show menu of priority 2 & 3 controls 

Prioritv 2 Controls - fielding 
(none) 
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Genre 8; 2D Object Control (CAD) 

Priority 1 Controls 
Semantic 



Move 

5 View 
Zoom 
Select 
Special 1 
Special 2 

10 Specials 
Special 4 
Menu 
Priority 2 Controls 
Semantic 

15 Rotate Z 

Display 
Device 



Description 

move object or scroll view up / down / left / right 
select between move and scroll 
in / out 

do first special operation 

do second special operation 

do third special operation 

do fourth special operation 

pause, show menu of priority 2 & 3 controls 

Description 

rotate object or view clockwise / counterclockwise 
shows next on-screen display options, etc. 
displays input device and controls 
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HIT) Implementation 

Fig. 9 shows an implementation of a computer and/or game system that is 
compatible with the Universal Serial Bus (USB) and Human Device Interface 
(HID) specifications. Both of these specifications are available from USB 
5 Implementers Forum, which has current administrative headquarters in Portland, 
Oregon (current Internet URL: www.usb.org). 

The system of Fig. 9 includes a computer 600 and a computer peripheral, 
game control device 601. The computer is a conventional desktop PC or other type 
of computer. Computer 600 runs an operating system 602 such as the Microsoft 
10 "Windows" family of operating systems. The operating system provides various 
system services to one or more application programs 603 running on computer 600. 
Computer 600 also has a USB communications driver and port 604. 

Control device 601 is one of any number of different types of controllers, 
such as a joystick, keypad, etc. It has a plurality of human-actuated controls such as 
15 buttons, sliders, and other Well-known input and/or output controls. A physical 
example of such a controller is shown in Fig. 6. 

The control d6vice has a USB port 605 and communicates with computer 
600 via a USB conmuriicatibns medium 606. In addition, control device 601 is 
configured to store various HID data 607 such as various device class descriptors 
20 defined by the HID standard. The HID descriptors enumerate and describe aspects 
of the control device's controls, and are formatted as specified by the HID standard. 
The control device has non-volatile memory 608 in which the HID data is stored. 
HID data can be requested and obtained by computer 600 through the USB 
communications cable. 
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structures, the controls are referenced by their HID string indexes. This allows 
subsequent correlation of the HID data with the non-HID data. 

Prior to using a HID control device in this implementation, a computer 
application program on computer 600 retrieves both the HID descriptors 607 and 
5 the non-HID descriptor 610 from control device 601. Within the non-HID 
descriptor, the computer locates data corresponding to a particular genre, and 
extracts the appropriate control mappings from the non-HID descriptor. Each 
control mapping indicates a control (referenced by its HID string index) and an 
associated action. The computer then uses the specified string indexes to correlate 
10 the control mappings to the actual controls specified by the HID descriptor. 

The described technique relies on a predefined definition of genres, as 
described in the previous section of this document. Within the non-HID data 
structures discussed below, the various genres and the actions defined within the 
genres are identified by different constants such as predefined numeric identifiers. 
15 Tiiis is illustrated more clearly in Fig. 10, which show the structure and 

content of a non-HID genre descriptor 610 in accordance with the described 
embodiment. Descriptor 610 includes four major sections: a header section 611, a 
control section 612, a genre section 613, and a diagram section 614. 
Header section 611 contains the following fields: 
20 • dwLength — ^the total length of the genre descriptor; 

• bVersion — ^the version number of the genre descriptor; 

• bNumConirols — the total number of controls present on the control 
device; 

• bNumGenres — ^the total number of genre supported by the control 
25 device, in order of manufacturer's preference; 
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sets forth a different HID string index. This string index corresponds 
to the HID sti-ing index as found in the HID descriptors. 
bOverlayNumber—\dentirits the overlay associated with the control, 
with reference to the bDiagramlndex field of the diagram section (see 
below). 

wXOJfset—ihe location in the X dimension of the control in the 
indicated overlay (bOverlayNumber) from the top left of the overlay. 
wYOffset—±e location in the Y dimension of the control in the 
indicated overlay (bOverlayNumber) from the top left of the overlay. 
wZOffset—^G location in the Z dimension of the control in the 
indicated overlay (bOverlayNumber) from the top left of the overlay. 
Used only in 3-dimensional diagrams. 

vuATVorma/— indicates information regarding the Normal in the X 

direction. The three normal coordinates (see immediately below) 

specify a 3-dimensional vector which is used to orient pointers or lead 

lines when showing different rotations of the device. 

wlWormfl/— indicates information regarding the Normal in the Y 

direction. 

wZN^onna/— indicates information regarding the Normal in the Z 
direction. 

bNumPointerSegments—^e TOxmber of segments in the lead line 
corresponding to the control: The following wXSegment, wYSegment, 
and wZSegment fields are repeated for each indicated segment (up to 
a limit of four). 

wXSegment— X coordinate of the base of an arrow segment. 
wYSegment— Y coordinate of the base of an arrow segment. 
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• bOverlaytoDiagram — if this diagram is an overlay, contains the 
bDiagramlndex of the underlying diagram. If this diagram is not an 
overlay, the bOverlayToDiagram field is set to zero. 

• bDiagramData — the actual diagram data structure (.bmp, Jpg, -gif, 
5 etc.) 

Fig. 1 1 shows methodological aspects of this embodiment. Methodological 
features include an act 670 of defining a plurality of application program genres. 
Each such genre includes potential actions to be performed in an application 
10 program of that genre. 

Act 671 comprises running an application program that has been classified 
as a particular genre. The application program is responsive to a plurality of 
human-actuated controls on a peripheral control device such as control device 601 . 
An act 672 comprises querying the control device to obtain a non-HID genre 
15 descriptor of the type shown in Fig, 10. Generally, the genre descriptor indicates 
actions to be performed by an application program of a particular genre in response 
to respective controls of the control device. As discussed above, the genre 
descriptor references controls by there HID string indexes. 

Act 673 comprises retrieving one or more HID descriptors from the control 
20 device to determine various details regarding the controls and also to determine 
their string indexes. 

Act 674 comprises correlating the controls with actions as specified by the 
non-HID descriptor. Act 675 comprises respondmg to the controls by performing 
the correlated actions in the application program. 
25 In the system shown in Fig. 11, these steps are performed in conjunction 

with system services that are independent of the application program, such as part 
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(device* interface, endpoint, or other). The primary types of 
requests specified in the "request type" field are the "standard" and 
"vendor" types, which will be discussed below. 

• bRequest—^ request code indicating one of a plurality of different 
5 commands to which the device is responsive. 

• wValue — a field that varies according to the request specified by 
bRequest. 

• wlndex—2i field that varies according to request; typically used to 
pass an index or offset as part of the specified request. 

10 • wLength — ^number of bytes to transfer if there is a subsequent data 

stage. ' ' ' ■ 

All USB devices are supposed to support and respond to "standard" 
requests— referred to herein as *TJSB-specific" requests. In a USB-specific request, 
the retjuest type portion of the bmRequestType field contains a predefmed value 
15 indicative of the "standard" request : ■ 

Each different USB-specific request has a pre-assigned USB-specific request 
code, defined in the USB specification. This is the value used in the bRequest field 
of the device request, to differentiate between different USB-specific requests. For 
each USB-specific request code, the USB specification sets forth the meanings of 
20 wValue and windex, as well as the format of any returned data. 

USB devices can optionally support "vendor" requests— referred to herein as 
"device-specific" requests. In a device-specific request, the request type portion of 
the bmRequestType field contains a predefined value indicate of the "vendor" 
request type. 

25 In the case of device-specific requests, the USB specification does not assign 

request codes, define the meanings of wValue and windex, or define the format of 
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(meanings of bindex, bVahie, etc.) is as specified in the definition of the host- 
specific device request. Phase 677 is repeated as desired during subsequent 
operation, without repetition of initialization phase 100. 

Fig. 13 shows more details regarding -the initialization phase 676. Actions 
5 performed by the host are on the left, and actions performed by the device are on 
the right. 

The host performs an action 680 of sending a GET_DESCRIPTOR device 
request to the peripheral device. The GET_DESCRIPTOR device request is a 
standard, USB-specific request, identified "in a control transfer by the 
10 GET^DESCRIPTOR request code {bRequest = GET_DESCRIPTOR). The fields 
of the control transfer (discussed above in the background section) have values as 
follows: 

• bmRequestType = 10000000 (binary), indicating a "device-to-host" 
transfer, a "standard" or "USB-specific" type request, and a device 

15 recipient. 

• Z?i?e^Me5^== GET^DESCRIPTOR. This is a constant (six) defmed 

by the USB specification ' 

• wValue = 03EE (hex). The high byte (03) indicates that the request 
is for a "string" descriptor, and the low byte is an index value that 

20 is predefined as a constant in the definition of the host-specified 

device request. In tiiis example, it has been defined as EE (hex), 
but could be predefined as any other value. 

• . windex =0. 

• wLength = 12 (hex). This is the length of a host-specific request 
25 descriptor that will be returned in response to this request. In the 

described example, the length is 12 (hex). 
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example MSFTIOO indicates that this descriptor is for an "MSFT" 
host-specific device request, version "1 00" or 1 .00. 
• bVendorCode — ^the device-specific request code that is to be 
associated with the host-specified device request. 
5 • bPad — a pad field of one byte. 

The host receives the host-specific request descriptor (block 684) and then 
performs an action 685 of checking or verifying the signature and version number 
found in the qwSignature field. The correct signature confiirms that the device is 
configured to support host-specific request codes. If either the signature or version 
10 number are incorrect, the host assumes that the device does not support host- 
specific request codes, and no further attempts are made to use this feature.^ ...^ 

The signature field of the host-specific request descriptor block is what 
provides backward compatibility. A non-compatible device (one that doesn't 
support host-specific request codes) might use the predetermined wValue 03EE 
15 (hex) to store some other type of descriptor, which will be returned to the host 
wifliout any indication of problems. However, this will become apparent to the host 
after it examines the data in the location where the signature is supposed to be. If 
the signature is not found, the host knows that the returned descriptor is not of the 
type requested, and will asisume that the device does not support host-specific 
20 request codes. ■ ' ^; - • ^ : 

\ b-Mr; If the signature? and version are confirmed in block 585, the host reads the 
device-specific request code from the bVendorCode field, and uses it in the future 
as a host-specific request code (block 686), to initiate the host-specific device 
request. When using the device, the host sends the host-specific device request by 
25 specifying the obtained device-specific request code as part of a control transfer. 
The device responds by perfomaing one or more predefined actions or fimctions that 
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CLAIMS 

1. A game control device that conforms to Universal Serial Bus (USB) 
device class definitions for Human Interface Devices (HIDs), comprising: 

a plurality of human-actuated controls; 
5 one or more HID descriptors that describe aspects of the human-actuated 

controls, the HID descriptors associating HID string indexes with the respective 
human-actuated controls; 

control mappings corresponding to a plurality of application program genres, 
the control mappings indicating actions to be performed in application programs of 
10 particular genres in response to respective ones of the human-actuated controls, 
wherein the control mappings identify controls by their HID string indexes. 

2. A game control device as recited in claim 1, the control mappings 
being indicated in data sets comprising: 

15 a control section indicating the HID string indexes for the respective 

controls; 

a genre section indicating actions to be performed in application programs of 
particular genres in response to respective ones of the human-actuated controls. 

20 3. A computer peripheral comprising: 

a plurality of human-actuated controls; 

non-volatile memory contaming control mappings corresponding to a 
plurality of application program genres, the control mappings indicating actions to 
be performed in application programs of particular genres in response to respective 
25 ones of the human-actuated controls. 
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8, A computer peripheral as recited in claim 0, the non-volatile memory 
containing a descriptor comprising: 

a control section indicating string indexes for the respective controls, the 
string indexes corresponding to separately defined human device interface (HID) 
5 string indexes; . 

a genre section indicating the control mappings for the respective application 
program genres, the control mappings identifying controls by their HID string 
indexes. 

10 9. A computer peripheral as recited in claim 0, the non- volatile memory 

containing a descriptor comprising: 

a header section indicating the number of controls on the computer 
peripheral and the number of genres for which control mappings exist in the non- 
volatile memory; 

15 a control section indicating string mdexes for the respective bontrols; 

a genre section indicating tlie control mappings for the respective appUcation 
proigrani genres; 

a diagram section containing one more graphics images of the computer 
peripheral, the one or more graphics images identifying locations of the human- 
20 actuated controls on the computer peripheral. 

lO, A computer peripheral as recited in claim 0, the non-volatile memory 
also containing control data that indicates: 

string indexes for the respective controls; 
25 graphics overiays that identify the human-actuated controls on the computer 

peripheral; 
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14. A method comprising: 

defining a plurality of application program genres; 

running an application program that has been classified as a particular 
application program genre, wherein the application program is responsive to a 
plurality of human-actuated controls on a control device; 

querying the control device to obtain a genre descriptor, the genre descriptor 
indicating actions to be performed by an application program of said particular 
application program genre in response to respective ones of the human-actuated 
controls. 



15. A method as recited in claim 14, wherein the obtained genre 
descriptor comprises: 

a control section indicating string indexes for the respective controls; 
a genre section indicating the control mappings for the respective application 
15 pirogram genres. 

16. A method as recited in claim 14, further comprising: 

retrieving one or more HID descriptors from the control device, the HID 
descriptors describing aspects of the human-actuated controls, the HID descriptors 
20 associating HID string indexes with the respective human-actuated controls; 

wherein the obtained genre descriptor identifies the human-actuated controls 
by their HID string indexes. , 
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20. A method as recited in claim 14, wherein the obtained genre 
descriptor comprises: 

string indexes for the respective controls; 
5 graphics overlays that identify the human-actuated controls on the control 

device; 

coordinates of the graphics overlays; 

coordinates for pointers to the human-actuated controls. 

10 21. A method as recited in claim 14, wherein the obtained genre 

descriptor comprises: 

a header section indicating the number of controls on the control device and 
the number of genres for which control mappings exist in the non-volatile memory; 
a control section indicating string indexes for the respective controls, the 
15 control section also indicating graphics overlays that identify the human-achiated 
controls on the control device; 

' ' a genre section indicating the control mappings for the respective application 
program genres; . 

20 22. A ineithod as recited in claim 14, wherein the obtained genre 

descriptor comprises one more graphics images that identify the locations of the 
human-actuated controls on the control device. 
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26. A computer-readable storage medium as recited in claim 23, wherein 
the obtained genre descriptor comprises: 

a control section indicating string indexes for the respective controls, the 
string indexes corresponding to separately defined human device interface (HID) 
string indexes; 

a genre section indicating the control mappings for the respective application 
program genres, the control mappings identifying controls by their HID string 
indexes. 



27. A computer-readable storage medium as recited in claim 23, wherein 
the obtained genre descriptor comprises: 

a header section indicating the number of controls on the control device and 
the number of genres for which control mappings exist in the genre descriptor; 
15 a control section indicating string indexes for the respective controls; 

a genre section indicating the control mappings for the respective application 
program genres; 

a diagram section contiaining one more graphics images of the control 
device, the one or more graphics images identifying locations of the hmnan- 
20 actuated controls on the control device. 

28. A computer-readable storage medixmi as recited in claim 23, wherein 
the obtained genre descriptor comprises: 

string indexes for the respective controls; 
25 graphics overlays that identify the human-actuated controls on the control 

device; 
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32. A data transmission medium carrying a data structure comprising: 
a header section indicating the number of human-actuated controls on a 

computer peripheral and the number of application program genres for which 

control mappings exist in the data structure; 
5 a control section indicating HID string indexes for the respective controls on 

the computer peripheral; 

a genre section indicating control mappings for the respective application 

program genres. 

10 33. A data transmission medium as recited in claim 32, further 

comprising: 

a diagram section containing one more graphics images of the computer 
peripheral, the one or more graphics images identifying locations of the human- 
actuated controls on flie computer peripheral. 

34. A data transmission medium as recited in claim 32, wherein the 
control section also indicates graphics overlays that identify the human-actuated 
controls on the computer peripheral. 

20 35. A data transmission medium as recited in claim 32, further 

comprising a diagram section, the diagram section comprising graphics overlays 
that identify the human-actuated controls on the computer peripheral; 

wherein the control section indicates coordinates of the graphics overlays 
and coordinates for pointers to the human-actuated controls. 

25 
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